Almathera Ten Pack 3: CDPD 3/Almathera Ten on Ten - Disc 3: CDPD3.iso/ab20/ab20_archive/games/strategy/empire-2.2w.lzh/Doc/Maintenance

Text File | 1990-08-30 | 7KB | 143 lines

    Amiga Empire Maintenance by David Wright

If, during a game, you should happen to have a power outage, a system
failure, GURU, or you don't properly shut Empire down, it is quite likely
some data will be corrupted.

This is because Empire stores a large amount of data in RAM while the server
is running to increase speed. If the system just gets turned off without
letting the server write the data to disk, it is possible for the data on
the disk to become "confused" or corrupted.

The best way to avoid this is to make sure you ALWAYS shut down the Empire
server before turning your machine off or rebooting, and be sure and wait a
few secs for AmigaDOS itself to write out it's own buffers. You should also
avoid running other software if you are not sure it can be trusted. It is
very exasperating to have a program tromp on the input handler leaving you
with no way to shut down Empire.

Of course, there is not much you can do about power failures, and this
document is about recovering or correcting your data after one of these
problems occurs.


Prevention

In this case it is certainly true that an ounce of prevention is worth a
pound of cure, and after the first time an irate user leaves you a message
about losing an entire sessions worth of moves, you will certainly want to
do what you can to prevent it from hapening in the future.

In the ideal situation you will have a system similar to mine, with a
complete uninteruptable power system capable of running the host long
enough during a total power outage to properly shut down the game, and
some kind of power conditioner to boot (Give me a call at 216-228-1400
and I will tell you the type of power system I reccomend for any Amiga
system).

Of course, I understand that this is most likely NOT the environment most
people have available to them, and Amiga Empire has about all the
features you should need to insure maximum data integrity.

Depending on the level of protection you need, and the kind of system you
run (and are running on), you can turn on various flags that will enable
"flush" modes ranging from only at system shutdown or deity command (as in
Empire 2.1w), to a super safe system which flushes the buffers every time
a country logs out, a client shuts down, and a normal country using the
flush command while they are online.

All of these flags are completely indipendant, so you can customize the way
Empire works to your own needs.

If you would like the serial client to flush the buffers when a country
logs out, you may use the FLUSH command line option or WorkBench tooltype
(for more info on SEREmp, see the SEREmp manual). Note that this ONLY
affects SEREmp if you are running it in the standalone mode (where SEREmp
itself answers the call). SEREmp does not do any kind of flushing when
it is used in the single call mode, as that is affected by the next flag.

If you would like Empire to flush all buffers every time a client terminates,
you can set this inside Empire itself. Use the "edit flags" command to
change the "Flush buffers on client termination" flag to YES. When this is
enabled ANY client terminating will flush the buffers, including the
local client (empire), and the Empire front-end (Empfe(when used in local
mode)). There is no need to set the SEREmp flush flag if you are going to
be using it in single use mode if this flag is turned on. This flag will
stay set until you edit it again.

If you would like any country to be able to flush the buffers, you may use
the "edit world" command to change the "Allow normal users to flush
buffers" flag to YES. With this set, the flush command will show up on all
active countries command list, and they may use it to write buffers to
disk multiple times while they are online.


Repairing Problems

The most common problems relate to item counts not matching the number of
items actually on disk, for example, Empire thinking there are 50 ships
while there are only 45 stored on disk.

You can identify these kinds of problems by using the "verify limits"
command. This will go through the database files that grow during use
and try to read in as many items as it thinks there are.

     You should always use this option FIRST after having a system
     crash!!!


Watch the numbers, and if it hangs up somewhere, remember what the last item
displayed was. After reloading the software (if needed), use the
"edit world" command to bring down the count of whatever item the system
printed before crashing, and set the correct limit to that value. For
example, if the system crashed while trying to read ship 3, reload Empire,
and edit the world so that the "next ship" field equals 3.

In general, the first thing you should do after a crash to use the
"verify all" command to check the limits as described above, and then to
check all other items if the limits are OK.

You should always (at least in most cases) answer "yes" when Empire reports
it found a problem. It is probobly better to let Empire fix the problem
and have someone lose a single ship (whose number will appear in the log
anyway, and so can be given back) than to have Empire blow up later and
cost someone an entire assault, naval battle, or even totally hose the rest
of your data.

    While Empire will LET you answer "no", YOU DO SO AT YOUR OWN RISK!
    Because of the limitless ways that data can be munged, Empire may fail
    during other tests if you fail to correct a problem it reported
    earlier!

If there are a lot of errors in the data file, you can save yourself the
hassle of typing in "yes" or "no" all the time by using one of the shortcut
keys. You can use the "a" key to indicate "yes to this and all future
questions", and the "q" key to indicate "no to this and all future
questions". So, for instance, to use the verify command in a purely scanning
method, and not correct ANY errors that occur, you would use type "q" at the
first error that occurs. (But did I mention that this is not advised?)

    Key summary:

    y = fix this error
    n = do not fix this error
    a = fix this and all future errors
    q = do not fix this or any future errors

Since all errors found appear on both the screen and in the log, it is very
important to have the log somewhere safe, not in an unrecoverable RAM
disk or on the same drive as the files you are trying to verify.
And since the errors try to give you as much info as possible, you may use
the log to try and rebuild the file by hand, if you don't trust the
verify command to do it right.

When dealing with inter-related items, it is always better to verify a file
again if a related database reported an error. For instance, if you were
verifying the ship database, and it found an error relating to fleets,
it would be wise to reverify the fleet database after you have corrected
the ship database. One good way to do this is to use the "verify all"
option, which will run ALL the verify tests. If your database is correct,
you should get no errors. (This can take some time!!).